feat(host): implement Registerable for MultiUseSandbox#1392
Merged
danbugs merged 1 commit intohyperlight-dev:mainfrom Apr 21, 2026
Merged
feat(host): implement Registerable for MultiUseSandbox#1392danbugs merged 1 commit intohyperlight-dev:mainfrom
danbugs merged 1 commit intohyperlight-dev:mainfrom
Conversation
The primary entry point for registering host functions is the UninitializedSandbox — that's the lifecycle phase where the guest hasn't yet been allowed to issue host calls, so the registry can be populated safely up front. There are, however, cases where a MultiUseSandbox is obtained without traversing the Uninitialized → evolve() path: - Sandboxes loaded from a persisted snapshot. - Any future API that yields a MultiUseSandbox directly. In those cases the caller never had a chance to call register_host_function on an UninitializedSandbox. Today they have to drop down to internal fields or fork the registry manually. Extend the Registerable trait impl to MultiUseSandbox so late registration is a one-liner. Semantics are unchanged: the guest's dispatcher resolves host functions by name at call time, so inserting into the registry after evolve() is safe as long as the first host-call happens after registration completes. Also flips MultiUseSandbox.host_funcs from pub(super) to pub(crate) so the impl in src/func/host_functions.rs can reach it. Signed-off-by: danbugs <danilochiarlone@gmail.com>
jprendes
approved these changes
Apr 21, 2026
Contributor
jprendes
left a comment
There was a problem hiding this comment.
LGTM.
I guess this opens some questions, like what's the point of the UninitializedSandbox?
Sounds like it's only use is "existing before hyperlight_main".
Do we still need it?
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Extends the
Registerabletrait impl toMultiUseSandboxso host functions can be registered on a sandbox afterevolve(). Today the only impl is onUninitializedSandbox, which works fine for the standardUninitialized → evolve() → MultiUseflow — but not for paths that yield aMultiUseSandboxdirectly. Examples: sandboxes loaded from a persisted snapshot (the snapshot-to-disk work lands one such path), and any future API with the same shape.Without this, those callers have to reach into internal state or maintain a parallel registry, which isn't a stable story. With it, late registration becomes a one-liner that mirrors the existing
UninitializedSandboximpl exactly.Semantics
The guest's host-function dispatcher resolves by name at call time. Inserting into the registry after
evolve()is safe as long as the first host-call invocation happens after registration completes. The typical usage pattern is the same as today for the pre-evolve path:Changes
impl Registerable for MultiUseSandboxnext to the existingUninitializedSandboximpl insrc/func/host_functions.rs. Body is a verbatim copy of the existing impl — same error handling, same lock acquisition, sameFunctionEntryconstruction.MultiUseSandbox.host_funcsnudged frompub(super)topub(crate)so the impl insrc/func/can reach it. No external API change.Tested
cargo check+cargo test -p hyperlight-hostlocally on Linux. No behaviour change for any existing caller.